Method and system for dynamic resource allocation

ABSTRACT

Embodiments of the present invention provide a dynamic resource allocator to allocate resources performance optimization in, for example, a computer system. The dynamic resource allocator to allocate a resource to one or more threads associated with an application based on a performance rate. Embodiments of the present invention may further include a performance monitor to monitor the performance rate of the one or more threads. The dynamic resource allocator to allocate an additional resource to the one or more threads, if the thread is performing above a performance threshold. In embodiments of the present invention, the dynamic resource allocation strategy may be decided based on, for example, optimizing the overall system throughput, minimizing power consumption, meeting system performance goals (e.g., real time requirements), user specified performance priorities and/or application specified performance priorities.

TECHNICAL FIELD

The present invention relates to computer systems. More particularly,the present invention relates to allocation of resources between threadsin a computer system that supports simultaneous multi threading.

BACKGROUND OF THE INVENTION

A typical computer system consists of several basic components and/orresources, including a processor, volatile and non-volatile memory, andvarious peripheral devices, including graphics controller(s), massstorage devices, and input/output devices. A chipset connects thesecomputer system components together, and manages the flow of informationbetween them. Known protocols may be used by the computer system forcommunications among system components.

Moreover, a processor in a computer system may include a plurality ofdifferent units such as instruction fetch unit, decode unit, executeunit, memory unit, retirement unit, etc. These units may include aninstruction pipeline that processes instructions. These units maycontain resources that are allocated for processing threads associatedwith one or more applications or other program(s) being processed by thesystem. As a computer system processes the one or more applications,processes or threads associated with these applications may compete forlimited resources.

In a multi-threaded micro-architecture processor, these limitedresources may be used by multiple threads, or logical processors withhardware support. In a typical processor, some resources may bepartitioned so the threads have equal shares while others are fullyshared. Inefficiencies may arise when resources are staticallypartitioned or allocated. For example, if resources are divided equallyamong threads (e.g. divided in half between two resources), then onethread may optimally utilize its half of the resources while the otherthread only partially utilizes its half. This may occur if one threaddoes not need that particular resource as much as the other does and soits allocation of the resource is wasted while the other thread coulduse it. If a computer system is not fully using all its resources it maydeliver lower overall system performance.

For example, a word processor running on a computer system may competefor resources with a CD (compact disc) player processing audio files onthe same system. In this example, the re-order buffer resources may beequally allocated to threads associated with each of these applications.While the word processor application may utilize its cache resources totheir maximum extent, the audio application may not need all of thecaching resources and under-utilizes these resources. Although the audioapplication will require sufficient resources so that the applicationoffers good sound quality, some resources allocated for threadsassociated with the audio application may be wasted.

When resources are fully shared among threads, fairness issues can ariseresulting in similar inefficiencies. One thread that allocates theresource faster but not necessarily for the execution of usefulmicro-ops can take over most of the resource, in expense of the otherthread(s) that may be doing more useful tasks.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of example,and not limitation, in the accompanying figures in which like referencesdenote similar elements, and in which:

FIG. 1 is a block diagram of a computer system in accordance with anembodiment of the present invention;

FIG. 2 illustrates a block diagram of a system in accordance with anembodiment of the present invention;

FIGS. 3A and 3B illustrate detailed block diagrams in accordance with anembodiment of the present invention; and

FIG. 4 is a flow chart illustrating a method in accordance with anembodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention provide a system and method fordynamic resource allocation in a computer system. The invention mayprovide a technique for allocating resources efficiently so that thesystem can achieve optimal performance. Embodiments of the presentinvention provide a system that dynamically allocates resources to, forexample, threads so that resources are efficiently and optimally used.

In one embodiment, the invention provides a dynamic allocation ofresources for each thread through a feedback system. Inefficienciesencountered by conventional systems may be reduced and the overallperformance may be improved while the overall power usage of amulti-threaded microprocessor may be reduced.

FIG. 1 is a partial block diagram of a system 100 in which theembodiments of the present invention find application. As shown in FIG.1, the system 100 may be a partial representation of computer and/or anyother device including these components. System 100 may include aprocessing unit 110 (processor) connected to a chipset 130 via a memorycontroller hub (MCH) 120. The processor 110 may be coupled to the MCH120 using, for example, a host bus 104 and the MCH 120 may be coupled tothe chipset 130 using bus 105. The MCH 120 may be coupled to a memory195 via bus 190. In embodiments of the present invention, bus 105 may beA Peripheral Component Interconnect (PCI) bus, PCI Special InterestGroup (SIG) PCI Local Bus Specification, Revision 2.2, published Dec.18, 1998, high-speed proprietary data bus (e.g., a hub bus) and/or anyother proprietary bus.

In accordance with embodiments of the present invention, a dynamicresource/thread allocator (DRA) 141 and/or a performance monitor (PM)142 may be further coupled to bus 105.

In accordance with embodiments of the present invention, the chipset 130of computer system 100 may include, for example, a controller 131,hublink module 132, and/or peripheral devices 133. These devices may becoupled to each other via an internal bus 160. The internal bus 160 maybe, for example, an ISA (Industry Standard Architecture) bus, a SMBus(System Management Bus), a PCI bus and/or any other type of bus.

It is recognized that chipset 130 and/or system 100 may includeadditional devices and/or components that have been omitted forsimplicity. These may include additional input/output (I/O) interfaces,memories, mass storage devices, etc. The various devices shown in FIG. 1and/or discussed herein are referred to hereinafter as resources. Theseresources may, for example, process application threads, instructions,micro-instructions, or other data (commonly referred to herein asthreads) which may be associated with one or more applications processedby system 100, in accordance with embodiments of the present invention.

In embodiments of the present invention, system 100 includes a pluralityof internal and/or external communication buses that connect the variouscomponents internal to and/or external to the client 100. These bussesmay include, for example, host bus 104, PCI or proprietary bus 105,internal bus 160, SMBus 150, PCI bus 138, PCI bus 155 and/or other PCIbuses (not shown).

In embodiments of the present invention, the processing unit 110 may beany type of processor such as a Pentium® processor manufactured by IntelCorporation of Santa Clara, Calif. or the like. Memory 195 may be anytype of memory such as a static random access memory (SRAM), dynamicrandom access memory (DRAM), a read only memory (ROM), extended data-outRAM (EDO RAM) and/or any other type of memory.

In embodiments of the present invention, PM 142 may monitor theoperating performance of the various resources included in system 100.Moreover, the PM 142 may also observe the performance of applicationthreads, instructions, or the like.

In embodiments of the present invention, the PM 142 may observe that theperformance impact of a certain resource for a particular applicationmay have a “good” region where performance may be enhanced if additionalresources and/or threads are added to the application. Moreover, the PM142 may observe a “flat” region where performance may not improve evenif more resources and/or threads are allocated. Based on thisobservation by the PM 142, the DRA 141 may allocate resources and/orthreads to optimize performance of the system, in accordance withembodiments of the present invention. Since different applications needdifferent resources, allocating additional resources of a particularkind to one application and additional resources of another kind toanother application may optimize the system when processing theparticular application.

Thus, take for example the earlier example, where a word processorapplication and the audio application running on a computer system suchas system 100 may compete for similar resources. The PM 142 may monitor,for example, memory resources such as memory or cache, located internalto a processor. If initially, resources are equally allocated to threadsassociated with each of these applications, the performance monitor mayobserve that the word processor application may utilize its cacheresources to their maximum extent, the audio application may not needall of the caching resources and under utilizes these resources. The PM142 may pass along its observations to the DRA 141. The DRA 141 withthis information and maybe additional data may reallocate resourcesand/or threads in accordance with the performance of each resourceand/or thread. For example, the DRA 141 may incrementally allocateadditional memory resources to the threads associated with the wordprocessor application while removing the resources from the threadsassociated from the audio application.

In embodiments of the present invention, the PM 142, for example, mayobserve that the performance of the word processor application and/orassociated resource is increasing as the additional resources areallocated. As a result, the DRA 141 may continue to allocate additionalmemory resources to the word processing application until theperformance of the application and/or resource reaches a performancethreshold. This performance threshold may indicate that the applicationand/or resource are operating in an optimal or “good” performanceregion. This performance threshold may be a pre-determined thresholdand/or may be dynamic threshold that may be periodically evaluatedand/or updated by the PM 142 and/or DRA 141. Once the PM 142 determinesthat the application and/or resource is operating at its operatinglevel, it may inform the DRA 141 to stop allocating additionalresources. Alternatively, the DRA 141 may allocate additional resourcesso that the application and/or resources operate faster and/or in a moreefficient manner. In embodiments of the present invention, the PM 142may continue to monitor the performance of the application and/orresources and the DRA 141 may adjust allocation of resources and/orthreads as needed. The DRA 141 may allocate additional resources toincrease performance and/or may remove resources and/or threads ifadditional allocations are not impacting the performance of theapplication, resource and/or system as a whole.

In embodiments of the present invention, the PM 142 may continue tomonitor the resource and/or other application (e.g., audio application)to observe the associated performance level. The DRA 141 may take thisinformation into account as it is removing resources from oneapplication (e.g., the audio application) and reallocating the resourcesto another application (e.g., the word processing application). The DRA141 may remove resources from an application up until the applicationstarts to fall below its performance threshold. At this point, the DRA141 may terminate removing additional resources and maintain the “good”performance region of the application (e.g., the audio application). Itis however recognized that the DRA 141 may remove additional resourcesand/or threads from one application even though the application fallsbelow its performance threshold.

Although DRA 141 and PM 142 are shown as two separate devices, it isrecognized that these devices may be incorporated into a single device,in accordance with embodiments of the present invention. Moreover,whether separate or together, DRA 141 and/or PM 142 may be locatedinternal to any of the various devices and/or components of computersystem 100. DRA 141 and/or PM 142 may also be located outside of thecomputer system 100.

In embodiments of the present invention, DRA 141 and/or PM 142 may beused to monitor and/or dynamically allocate resources in more than onecomputer system. For example, a DRA 141 and/or PM may be applied in anetwork environment and may monitor and/or allocate resources among oneor more computers, one or more servers, one or more storage devices,other devices and/or any combination thereof. The network may be alocal-area network (LAN), a wide-area network (WAN), a campus-areanetwork (CAN), a metropolitan-area network (MAN), a home-area network,an Intranet, Internet and/or any other type of computer network. It isrecognized that embodiments of the present invention may be applicableto more than one computer that are coupled together in, for example, aclient-server relationship or any other type of architecture such aspeer-to-peer network architecture. The network may be configured in anyknown topology such as a bus, star, ring, etc. It is further recognizedthat network may use any known protocol for communications.

As indicated above, in accordance with embodiments of the presentinvention, the DRA 141 and/or PM 142 may be incorporated in one or moreof the components of a computer system. For example, embodiments of thepresent invention may be incorporated within a processor such asprocessor 110.

FIG. 2 is a block diagram of a system including a processor 200 coupledto a memory 295 via a bus 290, in accordance with embodiments of thepresent invention. The processor 200 may be similar to processor 110,shown in FIG. 1, in accordance with embodiments of the presentinvention. It should be recognized that the block system configurationshown in FIG. 2 and the corresponding description is given by way ofexample only and for the purpose of explanation in reference to thepresent invention. It is recognized that the system shown in FIG. 2 mayinclude additional components. Moreover, processor 200 may be configuredin different ways and/or may include other components and/orsub-components. The processor 200 may include a plurality of pipelinestages including a plurality of components that may be located at thevarious stages of the pipeline. Although five units are shown, it isrecognized that a processor pipeline can include any number of units orpipeline stages.

In an embodiment of the present invention, the processor 200 may includeinstruction fetch unit(s) (IFU) 210, instruction decode unit(s) (IDU)220, instruction execution unit(s) (IEU) 230, memory units(s) (MEM) 240and retirement unit(s) (RU) 270. The IFU 210 may fetch instructions froma storage location, for example, an instruction cache, and the IDU 220may decode the instructions. For a Complex Instruction Set Computer(“CISC”) architecture, IDU 220 may decode a complex instruction into oneor more micro-instructions. Embodiments of the present invention may bepracticed for other architectures, such as Reduced Instruction SetComputer (“RISC”) or Very Large Instruction Word (“VLIW”) architectures.It is to be noted that no distinction is made between instructions andmicro-instructions unless otherwise stated, and are simply referred toherein as instructions.

In embodiments of the present invention, the IFU 210 may fetchinstruction byte(s) from memory and place them in a buffer until thebytes are needed. The instruction decode unit 220 may fetch and decodethe instruction by determining the instruction type and/or fetch theoperands that are needed by the instruction. The operands may be fetchedfrom the registers or from memory. The IEU 230 may execute theinstruction using the operands. The MEM unit 240 may store the operandsand/or other data. The RU 240 may retire the instructions as they areprocessed, in accordance with embodiment of the present invention.

It is recognized that pipeline stages shown in the processor 200represent a variable number of stages which may lie between IFU 210 andMEM 270. As processor frequency is increased, the number of stages inprocessor 200 may increase. This increasing prediction resolution timewill cause increasing penalty when speculation is incorrect.

In embodiments of the invention, a performance monitor (PM) 250 and/or adynamic resource allocator (DRA) 260 may be coupled to the processor200. The PM 250 may monitor, for example, the performance and/orprocessing status of the various components (resources) included in theprocessor 200. As indicated above, the components shown in processor 200are given by way of example only and that processor 200 may includeadditional components that have been omitted for simplicity. Performancemonitor 250 may be similar to and/or include the same functionality asPM 142, described above. DRA 260 may be similar to and/or include thesame functionality as the dynamic resource allocator 141, describedabove.

In embodiments of the present invention, for example, PM 250 may monitorthe performance of resources such as one or more IFUs 210, IDUs 220,etc. located in the processor 200. For example, the PM 250 may, forexample, generate a performance-resource curve associated with eachresource or the like. Based on the resource-performance curve, the PM250 may determine a good performance region as well as a flat region ofoperation. The PM 250 may observe the performance impact on theresources for one or more applications. For example, the PM 250 maymonitor the performance impact as the IFU 210, for example, processinstructions such as micro-instructions associated with an application.As the PM 250 monitors the performance of the various resources, it mayprovide this performance information to the DRA 260. Based on theinformation received from the PM 250 and/or performance thresholdlevels, the DRA 260 may allocate resources to the instructions and/orallocate instructions to the resources to optimize performance, forexample.

In one example, if an application is running in its good performancerange (e.g., at or above a performance threshold), the DRA 260 mayallocate additional resources to the application. For example, the DRA260 may assign one or more additional IEUs 230 to the application. Ifthe performance rating associated with the application improves,additional resources may be allocated to the application. If however,the performance rating associated with the application remains flat ordoes not improve (e.g., falls below a performance threshold), the DRA260 may cease to allocate additional resources to the application. Inembodiments of the present invention, the DRA 260 may even de-allocateand/or remove resources associated with the application so that theperformance of the application returns or remains at or above aperformance threshold.

In another example, if one of the components such as IFU 210 in theprocessor 200 is operating in the “good” performance (e.g., above aperformance threshold), the DRA 260 may allocate additional instructionssuch as micro-instructions to the resource. If, as a result of theadditional instruction allocation, the performance rating associatedwith the resource improves, additional instructions may be allocated toon or more resources. If however, the performance rating associated withthe resource remains flat or does not improve (e.g., falls below aperformance threshold), the DRA 260 may cease to allocate additionalinstructions to the application. In embodiments of the presentinvention, the DRA 260 may even de-allocate and/or remove instructionsassociated with the resource so that the performance of the resourcereturns or remains at or above a performance threshold.

FIGS. 3A and 3B illustrate block diagrams in accordance with embodimentsof the present invention. FIGS. 3A and 3B show how a dynamic resourceallocator 330 may allocate resources in a re-order buffer (ROB) 310, inaccordance with an embodiment of the present invention. The ROB 310 maybe included in an IEU 230 or another component of processor 200. It isrecognized that processor 200 may include additional components ordevices. It is recognized that the dynamic resource allocator 330 may beused to dynamically allocate resources to any number of differentcomponents and/or devices.

In embodiments of the present invention, the re-order buffer 310 mayinclude a plurality of resources 320 that may be allocated by thedynamic resource allocator 330 to threads T0 (thread zero) and T1(thread one). In the example provided, the added logic may control theallocation limits of each thread in the ROB. For simplicity, only twothreads (e.g., T0 and T1) are shown in FIGS. 3A and 3B, however it isrecognized that resources may be allocated among any number of threads.In other words, the dynamic resource allocator 330 may allocateresources among three, four or more threads.

In embodiments of the present invention, the performance of each threadis monitored by the logic included in the allocator 330. In one example,the allocator may monitor the micro-operation instruction retirementrate (uops per clock) calculated as a running average over a certainnumber of clocks. Based on this information, for example, the allocatormay apply one or more dynamic allocation strategies as described herein.

In embodiments of the present invention, the dynamic resource allocator(e.g., allocator 260 and/or 330) may use other criteria to monitorand/or allocate resources dynamically. For example, it is recognizedthat the overall system performance may be monitored and resources maybe allocated to optimize system throughput. In another example,resources may be allocated based on real time requirements such as realtime performance thresholds or the like. In yet another example,resources may be applied based on user defined specifications, and/orbased on specifications and/or requirements of the application beingprocessed.

In embodiments of the present invention, the dynamic allocator 330 mayobserve that the performance impact of a thread may have a “good” regionin the resource allocation curve where performance may be enhanced ifadditional resources are provided to the thread. Moreover, the dynamicallocator 330 may observe a “flat” region where performance may notimprove even if more resources are assigned. Based on this observation,the allocator 330 may allocate resources to threads to optimizeperformance of the system, in accordance with embodiments of the presentinvention. Since different applications need different resources,allocating additional resources of a particular kind to one thread andadditional resources of another kind to another thread may optimize thesystem when a particular kind of application is being processed.

In embodiments of the present invention, the allocator 330 may observethat resources 320 may be equally allocated to threads T0 and T1. Inother words, 50% of the resources 320 of ROB 310 may be allocated tothread T0 and 50% of the resources 320 may be allocated to thread T1. Inthis example, one thread is execution bound but may have a high rate ofbranch misprediction, it will keep filling its ROB resources 320 withmicro-operations (uops) that are frequently flushed. If another threadalso being processed by ROB 310, may have frequent bus accesses and maypermit other uops to execute between the bus accesses. Performance ofthe ROB 310 may be improved if resources are taken away from the firstthread and are allocated to the second thread. The allocator mayaccomplish this by, for example, monitoring the retirement rate of thethreads with increased resources.

In embodiments of the present invention, the dynamic allocator mayobserve that the performance of a thread is increasing as additionalresources are allocated. As a result, it may continue to allocateadditional resources to the thread until its performance reaches at orabove a performance threshold, or a flat region. This performancethreshold may indicate that the thread is running in an optimal or“good” performance region. This performance threshold may be apre-determined or it may be a dynamic threshold that is periodicallyevaluated and updated by the allocator. Once it determines that thethread is operating at its optimal level, it may stop allocatingadditional resources. Alternatively, the allocator 330 may allocateadditional resources so that the application and/or resources operatefaster and/or in a more efficient manner. In embodiments of the presentinvention, the allocator continues to monitor the performance of thethread and adjusts the allocation of its resources as needed.

In embodiments of the present invention, as shown in FIG. 3B, theallocator 330 may allocate 70% of the resources 310 to thread T0 and mayonly allocate 30% of the resources to thread T1. In embodiments of thepresent invention, the allocator can remove resources from thread T1,either to be able to provide them to another thread such as T0 that canutilize the resource more efficiently or to conserve power by taking outof the available pool an underutilized portion of resources until thethread starts to lose performance At this point, the allocator 330 mayterminate removing resources and even give back some of the resources torestore and maintain the “good” performance region of the thread.

In embodiments of the present invention, it is recognized that theallocator 330 may remove additional resources and/or threads from oneapplication. For example, if there are five (5) active threads, three(3) threads may be allocated to the word processor application. Theallocator 330 may recognize that the threads allocated to the wordprocessor may be reduced to two (2) or even one (1). Accordingly, theallocator 330 may remove threads from the word processor and reallocatethe threads to another program or application. The allocator 330 mayrecognize that the resources may be reallocated without impacting theword processor, for example. Moreover, the resources may be reallocatedto increase the overall throughput of the system or as designated by theuser and/or by the application.

It is recognized that the allocator 330 may include the features and/orfunctionality of the PM (e.g., PM 142 and/or PM 250) and/or the DRA(e.g., DRA 141 and/or 260). It is further recognized that allocator 330may be separated in to two devices (such as a PM and a DRA) and/or mayremain a single device that performs the functionality of both devices.In embodiments of the present invention, allocator 330 may be locatedinternal to and/or external to a component such the ROB 310.

In embodiments of the present invention, for example, the dynamicresource allocator 330 may monitor the performance of resources such as,but not limited to, ROB, memory ordering load and store buffers, ascheduler, fill request buffers, the bus queue, hardware prefetcherqueue, instruction streaming buffers, translation lookaside buffer,caches, etc. The allocator may, for example, generate aperformance-resource curve associated with each resource or the like.Based on the resource-performance curve, it may determine a goodperformance region as well as a flat region of operation. Based on thisinformation, the allocator may allocate resources to the instructionsand/or allocate instructions to the resources to optimize performance,for example.

In one example, if a thread is running in its good performance range(e.g., at or above a performance threshold), the allocator may allocateadditional resources to the thread. If the performance of the threadimproves, additional resources may be allocated to it. If however, theperformance remains flat or does not improve (e.g., falls below aperformance threshold), the allocator may cease to allocate additionalresource to the application. In embodiments of the present invention,the allocator may even de-allocate and/or remove resources associatedwith the application so that the performance of the thread returns orremains at or above a performance threshold.

FIG. 4 is a flowchart illustrating a method in accordance with anembodiment of the present invention. In an embodiment of the presentinvention, the performance rate of an application thread being processedby a resource may be sampled, as shown in box 410. If the applicationthread being processed at a rate above a threshold rate, additionalresources may be allocated to the application thread, as shown in boxes415 and 420.

In embodiments of the present invention, if the application thread isnot being processed at a rate above a threshold rate, blockingadditional resources from the application thread, as shown in boxes 415and 430.

In embodiments of the present invention, the dynamic resource allocationstrategy may be decided based on, for example, optimizing the overallsystem throughput, minimizing power consumption, meeting systemperformance goals (e.g., real time requirements), user specifiedperformance priorities and/or application specified performancepriorities.

Several embodiments of the present invention are specificallyillustrated and/or described herein. However, it will be appreciatedthat modifications and variations of the present invention are coveredby the above teachings and within the purview of the appended claimswithout departing from the spirit and intended scope of the invention.

1. An apparatus comprising: a dynamic resource allocator to allocate aresource to one or more threads associated with an application based ona performance rate.
 2. The apparatus of claim 1, further comprising: aperformance monitor to monitor the performance rate of the one or morethreads, wherein the dynamic resource allocator is to allocate anadditional resource to the one or more threads if the thread isperforming above a performance threshold.
 3. The apparatus of claim 2,wherein the dynamic resource allocator is to allocate the additionalresource to the one or more threads if the thread is performing at theperformance threshold.
 4. The apparatus of claim 2, wherein the dynamicresource allocator is to remove the resource from the one or morethreads if the thread is performing below the performance thresholds. 5.The apparatus of claim 1, further comprising: a re-order buffer coupledto the dynamic resource allocator, wherein the resource is a re-orderbuffer resource and the re-order buffer is to process the one or morethreads.
 6. The apparatus of claim 1, further comprising: a memoryordering buffer coupled to the dynamic resource allocator, wherein theresource is a memory ordering buffer resource and the memory orderingbuffer is to process the one or more threads.
 7. The apparatus of claim1, further comprising: a translation lookaside buffer coupled to thedynamic resource allocator, wherein the resource is a translationlookaside buffer resource and the translation lookaside buffer is toprocess the one or more threads.
 8. The apparatus of claim 1, furthercomprising: an instruction streaming buffer coupled to the dynamicresource allocator, wherein the resource is a instruction streamingbuffer resource and the instruction streaming buffer is to process theone or more threads.
 9. A method for dynamically allocating resources ina computer system, comprising: sampling a performance rate of anapplication thread being processed by a resource; if the applicationthread is being processed at a rate above a threshold rate, allocatingadditional resources to the application thread.
 10. The method of claim9, further comprising: if the application thread is being processed at arate below the threshold rate, blocking additional resources from theapplication thread.
 11. The method of claim 9, wherein the performancerate is a micro-operation instruction retirement rate.
 12. The method ofclaim 9, wherein the performance rate a throughput of the computersystem.
 13. The method of claim 9, wherein the performance rate is auser defined performance rate.
 14. The method of claim 9, wherein theperformance rate is an application dependent performance rate.
 15. Amethod comprising: monitoring performance of a resource in a computersystem; and allocating additional application threads to the resource,if the resource is performing above a performance threshold.
 16. Themethod of claim 15, further comprising: blocking an application threadfrom being allocated to the resource, if the resource is performingbelow the performance threshold.
 17. The method of claim 15, furthercomprising: removing an application thread from the resource, if theresource is performing below the performance threshold.
 18. The methodof claim 15, further comprising: allocating additional applicationthreads to the resource, if the resource is performing at theperformance threshold.
 19. The method of claim 15, further comprising:blocking an application thread from being allocated to the resource, ifthe resource is performing at the performance threshold.
 20. The methodof claim 15, wherein performance of the resource is measured by a numberof instruction per cycle that are processed by the resource.
 21. Asystem comprising: a processor; a bus; a dynamic resource allocatorcoupled to the processor via the bus, wherein the dynamic resourceallocator to allocate the processor's resource to one or more threadsassociated with an application based on a performance rate.
 22. Thesystem of claim 21, further comprising: a performance monitor coupled tothe processor and the dynamic resource allocator, wherein theperformance monitor is to monitor the performance rate of the processorand is to allocate an additional resource to the one or more threads ifthe thread is performing above the performance threshold.
 23. The systemof claim 21, wherein the dynamic resource allocator is to allocate theadditional resource to the one or more threads if the thread isperforming at the performance threshold.
 24. The system of claim 21,wherein the dynamic resource allocator is to remove the resource to theone or more threads if the thread is performing below the performancethresholds.
 25. The system of claim 21, wherein the performance rate isa throughput rate of the processor.
 26. A system comprising: a bus; anexternal memory coupled to the bus, wherein the external memory is tostore a plurality of instructions; and a processor coupled to the memoryvia the bus, the processor including: a dynamic resource allocator,wherein the dynamic resource allocator is to allocate the processor'sresource to one or more threads associated with an instruction from theplurality of instructions based on a performance rate.
 27. The system ofclaim 26, wherein the dynamic resource allocator is to monitor theperformance rate of the processor and is to allocate an additionalresource to the one or more threads if the thread is performing abovethe performance threshold.
 28. The system of claim 26, wherein thedynamic resource allocator is to allocate the additional resource to theone or more threads if the thread is performing at the performancethreshold.
 29. The system of claim 26, wherein the dynamic resourceallocator is to remove the resource to the one or more threads if thethread is performing below the performance thresholds.
 30. The system ofclaim 26, wherein the performance rate is a throughput rate of theprocessor.